IBIS Macromodel Task Group Meeting date: 06 March 2018 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte SPISim: * Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Radek: Motion to approve the minutes. - Mike L.: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD189 and BIRD158 related issues: - Arpad: At the Interconnect meeting they wanted us to review BIRD158 in the context of BIRD189. Radek had raised some issues. - Bob: Should we go into the "ground" discussion? - Arpad: Anything strictly BIRD189 related should be handled in the Interconnect meeting, but the ground issue is part of the BIRD158 vs BIRD189 issue, so we could discuss it here. - Radek: [having Arpad share his 'BIRD158 and BIRD189 Referencing Problems' slides from the ATM meeting on February 20th, 2018] - [BIRD158 figure showing the entire channel topology] - Diagram shows the channel, package, etc., and the 4 port S-parameter data provided by the Ts4File. - This is an AMI specific configuration. - The different pieces can be characterized with Touchstone files. - Figure shows a common reference for all of them, as we have discussed. - The real point is that the package should also be represented as a 4 port, and all of the terminals shown here are the I/O terminals, and this common reference node for all of them is the A_gnd (the local ground). - But a BIRD189 package model may not be created this way. It may also include other terminals related to the rails. We need to address that. - What we need in BIRD158 is the 4 port structures that span the I/O terminals and the common reference we will term A_gnd. - Interconnect model maker may provide exactly that, a 4 Port Interconnect model that spans pairs of differential I/O pins with A_gnd as the reference. - IBIS-ISS can be used as well, but the point is that A_gnd should still be there as the reference for the channel. - The problem is if the interconnect model provides other terminals for the rails, then we don't have a solution for that yet. My solution would be to tie one of the rails to A_gnd for this BIRD158 AMI application. - Walter: [sharing a private email related to common references] - There are three types of simulations: - 1. Not Power Aware - All rail voltages are DC voltages. - All reference nodes are connected to a "ground" node (i.e. a rail voltage with DC level 0V relative to a simulator global reference, e.g. node 0) or a single simulation reference node. - 2. Ground Based Power Aware - The voltage rails that are not "0" can vary with time and float. - All "ground" rail nodes are connected to a "ground" node (i.e. a rail voltage with DC level 0V relative to a simulator global reference, e.g. node 0) or a single simulation reference node. (e.g. tie all your VCC rails to node 0). - All reference nodes are connected to a "ground" node (i.e. a rail voltage with DC level 0V relative to a simulator global reference, e.g. node 0) or a single simulation reference node. - 3. Power Aware, where local "ground" nodes can float relative to a simulator or simulation reference node. - This requires an understanding by both the model maker and the tool he is using to generate interconnect models that correctly reference appropriate rail terminals at the buffer/die and at the pin. - BIRD189 allows the model maker and tool to create models with reference terminals that satisfy this requirement. - The model maker should document if all of the Interconnect Models in all of the Interconnect Model Sets in an Interconnect Model Group support case 3. - We may choose to add a keyword to the [Interconnect Model Group] that indicates that the Group is fully power aware. - Note that a fully power aware model can still be used in scenarios 1 and 2 by tying the references to 0V. - BIRD158 simulations are for AMI. They are LTI. They are not power aware when generating step responses for AMI simulations. It doesn't matter what the user did connecting reference nodes. The EDA tool is going to do a non- power aware simulation and tie all those reference nodes to A_gnd or node 0. - We may want to write this up more carefully along these lines, but there is nothing wrong with the existing format we have. - It just means that when someone is doing full power aware simulations that support the local ground node floating relative to node 0 they have to do it carefully. - I think text along these lines (3 types of simulation) could be added to the justification for the BIRD, or the BIRD text itself, and that could be the end of this discussion on A_gnd and power aware simulations. - Bob: I largely support what Walter has said. - I would add a clarification statement that for BIRD158 the full capability of BIRD189 is not supported nor relevant. - Walter: I don't agree with that statement. A fully power aware BIRD189 model is supported properly by BIRD158. You just recognize that you're not doing a power aware simulation with BIRD158, and tie the rail voltages to DC levels. - Radek: That's exactly what I've been asking for. We have an Interconnect Model Group, and we should spell out for the EDA tool and the user exactly how things should be handled for the application of BIRD158. We agree, but we have to spell it out. - Arpad: We are converging on a solution. - Which BIRD should be modified to add this text? - Radek: I think BIRD158 is okay already. - In BIRD189 we may want to add clarification on how models are used in AMI or non-power aware simulations. - Arpad: [referring to the "triangle ground symbol" Note that appears 3 times in BIRD158 (at the bottom of his full channel topology slide)] - Should we change the sentence: "This node would typically be the global ground, such as node 0 in IBIS-ISS." and replace the node 0 reference with the A_gnd we use in BIRD189? - Should we remove the "typically", which allows the EDA tool to do whatever it wants? Should we mandate the use of A_gnd? - Radek: We can't mandate the use of A_gnd for the channel block. That connection is made by the user or tool. The best solution is probably to remove that sentence entirely. - We already say (previous sentence) that they're all the same node. When we have BIRD158 used in conjunction with BIRD189, BIRD189 will say that node is A_gnd. - Discussion: Arpad noted that with the current understanding of A_gnd as a "local ground", it was local to a given component. Therefore, a Tx on one end and an Rx on the other might have A_gnd connected to different nodes. He therefore preferred to have BIRD158 state that the reference node for the TS4 file blocks is A_gnd, the local ground. Bob noted that BIRD158 did not have anything in its syntax to specify the reference node. Arpad noted that in the context of the recently added warning in BIRD189 strongly suggesting the use of A_gnd as the reference for the package model, a similar statement in BIRD158 that A_gnd would be the reference for the Ts4file Touchstone block made sense. Ambrish expressed concern for mixing the BIRD158 and BIRD189 warnings in case a model maker only wanted to read the BIRD158 section. He suggested BIRD158 might just need an additional warning that BIRD158 simulations are not power aware. Walter noted that BIRD158, since it is an impulse response based simulation, only requires the references to be connected to DC voltage levels. Radek suggested we might state that all ground references are assumed shorted to A_gnd in the absence of any more specific information. Arpad proposed a combination of Ambrish's warning with Radek and Walter's ideas, and said that we might state that if BIRD158 is used with a BIRD189 model, then the model maker should probably use A_gnd as the reference for the BIRD189 model. Arpad said he would take the AR to make this BIRD189 related cleanup to BIRD158. Since BIRD158 (BIRD158.7) is already approved, he asked what the group thought was the best way to do it. Bob disliked the idea of re-opening BIRD158. Arpad agreed to create a new BIRD that starts with the BIRD158.7 text and indicates the required changes. Mike L. asked why BIRD158 even showed the package model and channel in the figure. Arpad said it was to show common referencing for the entire channel. Arpad revisited slides 3 and 4 from his Feb 20th presentation. He noted that these illustrated the same thing as the full channel figure in BIRD158. He again discussed the possibility of an N+2 channel model, and he suggested that the current BIRD158 assumption that all the reference nodes are the same was not necessary. Walter noted that we could dramatically complicate the language of BIRD158 with additional changes, but that in practice we can safely assume that the reference nodes are tied together for BIRD158 simulations. He said when people build SERDES channels they are extremely careful to make sure all the references throughout the channel are well connected. Ambrish noted that he disagreed with Walter's statement. BIRD189: Rail Rule Relaxation: - Discussion: Arpad shared some figures he had created previously for a different discussion to illustrate the suggestions in Bob's Rail Rule Relaxation proposals. Walter noted that he thought the rule relaxation was unnecessary, and that we had demonstrated that decoupling cap modeling could be handled to Randy's satisfaction with the current BIRD189. Further discussion was deferred to the next Interconnect meeting. - Ambrish: Motion to adjourn. - Walter: Second. - Arpad: Thank you all for joining. AR: Arpad to prepare a draft of a new BIRD to supersede BIRD158.7. ------------- Next meeting: 13 March 2018 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives